STraTOS 1997 April & May/STraTOS 1 - 1997 April & May.iso/CD01/INTERNET/SITES/RAND/ALL95.LZH/letters_fj/text0003.txt

Text File | 1995-10-04 | 5.3 KB | 121 lines

Hi again,

> >I very nearly bought a TI99/4A, but given their history I was lucky.
> Well, I put two games on the market in France for this machine, and made
> about 30000FF with them, because people were frustrated of good soft. For a

:-)

> The QL never was very much developed here. BTW, where do you live exactly?

At least the QL shows that we need have no fear of our dear Ataris. There
is almost as much support for it now as there ever was. The machine itself
hasn't been in production for 10 years or so, but new hard and software is
still released. You can upgrade it by plugging in a fast 68020 card or buy
a _very_ cheap 68LC040 card to put in a PC for example.
(The '040 card with 4Mbyte RAM costs somewhere around 300 pounds!)

I live in Gothenburg, Sweden. You'll be able to see it on TV shortly, since
we have a _very_ big sports event coming up.
Check out the links on my WWW site for some nice pictures.

> >For a lot of things I really think we should use GCC. It produces very good
> >code (but far from usable for graphics of course) and there is likely to be
> >a _lot_ of general house keeping and such.
> Not so much, I think. Why?

Well, there always is...   ;-)

Perhaps 'general house keeping and such' wasn't a good expression. I tried
to group together everything but the actual graphics/sound. That would be
loading of WADs, writing of save files, menu handling, position tracking
etc. I think the AI had better be written in C as well if it's ever
going to work, at least if it's any good.
C compilers like GNU C are very good at what they do. The main problem is
that C can't express the sort of things you want to do in many graphics
routines for example. A portable language shouldn't.

> >MGIF I write everything in C at first and then optimize the most speed
> >critical parts (mainly GIF loader and various chunky to planar conversions)
> >by rewriting them in assembly. That way it's quick to get it all working.
> >I still keep all the original C code in the sources for the future.
> For most applications, it's the best way to work. But a game, like a demo,
> is a very different matter.

Perhaps if you want to use _every single_ cycle you've got, but there's
absolutely no point in doing that except for things that run say a couple
of thousand times per second or so (not ment specifically). On the PC side,
as well as most of the newer consoles, just about everything is done in C
or C++, with a couple of small assembly routines. DOOM itself is a good
example of just that.
The Falcon is not fast, but with a little DSP help it's not _that_ slow.

> >C++ as in dview is probably not a good idea, though, since virtual memory
> >would likely be needed to compile the program. I run Outside all the time,
> >but I don't know how common that is.
> Not very common.

Even among programmers?
How can anyone live with 4Mbyte on a Falcon, let alone program on it?
When I've loaded all the utilities and stuff I like to have available,
GCC would be hard pressed to compile a single line.

> >Having smarter monsters could be fun, but it could also make many levels
> >totally impossible.
> Why not make a parametrized smartness?

We'd have to find someone well versed in AI to do that kind of thing, I
think. Smartness is bad enough without making it variable.

Anyway, there are levels in DOOM where I think it's almost necessary to
make use of the specific behaviour of the monsters. If they were to run
around obstacles in new ways, things could get difficult.

> >Without the texture mapping, I think Descent would be doable. Certainly not
> >as fast as a non-textured DOOM, but not too bad either.
> Yes, of course descent would be doable without the textures, because then it
> becomes very similar to Starglider II.

Similar perhaps, but the world is much more complex IIRC. Mind you, I've
only played Descent for 5 minutes or so and Starglider around the same.

> Yes, and in fact, I think this should be an open project. I mean, the
> sources should be available for all to improve. BUT in order to keep some

I agree completely.

> coherence and compatibility between your version and that of your neighbour,
> all improvements should be sent to a single group or person so that it can

Yes.

> be included in an official new version. Otherwise, people would have to look
> in 12 different FTP sites and 34 BBSs to get the latest, complete thing.

We won't be able to avoid all of that anyway, but we should of course do
what we can.

> >Is the sound in DOOM directional? If not it should be very simple to add.
> >(The sound that is, not the directionality.)
> Yes, it is. But why would this be a problem?

Perhaps games mostly fake that kind of thing by using different volumes
for left and right. I think much/most studio recorded music does it that
way as well unfortunately. From speakers it may sound acceptable, but with
earphones it can be very distracting. For music this is usually not too bad
(I don't know why. Perhaps there's so much sound everywhere.), but in a game
where there's just a few sound sources it can sound really funny.

For real directional sound you'd have to phase shift an appropriate amount,
which I don't think is trivial (I've never tried, though).

The guys who made Substation seemed to be very proud of their sound engine.
Did that do more complicated stuff than directional sound?


Ooops, my train is leaving in a couple of minutes!

Regards,
Johan